search for: machinetypes

Hello. I'm not able to disable the sata controller on a machine='pc-q35-2.1' type VM. Whenever i delete: <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> it gets added again when i close the editor. The reason i would

On 02/23/2015 02:26 PM, Thomas Stein wrote: > Hello. > > I'm not able to disable the sata controller on a machine='pc-q35-2.1' type VM. > Whenever i delete: > > <controller type='sata' index='0'> > <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' > function='0x2'/> >

Hello. I'd like to determine if it's possible to change the 'machine type' attribute while a vm is running. For example, I have: <os> <type arch='x86_64' machine='pc-i440fx-trusty'>hvm</type> <boot dev='hd'/> </os> I'd like to change that to "machine='pc-i440fx-1.7'" due to an error[1]

Hi everyone, I incidentally configured two IDE controller for my machine-1.2 VM(it might be virsh attach-disk to blame), and I got the error message "Only a single IDE controller is unsupported...". I can't understand this error message, I think it means I HAVE to configure two or more IDE controllers until I looked it up in the source. At libvirt-1.2.22/src/qemu/qemu_command.c:

What's the status of the SATA controller migration bug? Are the patches for it expected to be in 2.4? Looks like they didn't make it into 2.3. Since you last wrote, if the SATA controller patches aren't in yet, is there any new way to avoid the SATA controller device, if you have no SATA devices? Thank you. === REPLYING TO === On 02/23/2015 02:26 PM, Thomas Stein wrote: >

Hello, I noticed that if include\llvm\Support is included alongside Windows.h, there will be many define conflict leading to compilation errors, such as: COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; and winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 Of course I could try to avoid to include both (but it's rather difficult and would require lot of refactoring -- we have this clash currently in LLDB MinGW32 port). I was wonderi...

Right now, we have: In COFF.h: class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; In windows.h: #define IMAGE_FILE_MACHINE_UNKNOWN 0 * If you first include COFF.h and then windows.h, COFF::IMAGE_FILE_MACHINE_UNKNOWN will be preprocessed into COFF:0. * If you first include Windows.h and then COFF.h, COFF.h won't wo...

I would really appreciate some pointers on what I am doing wrong here. I have a need to run multiple virtual guests which have each their own GPU and some USB controllers passed-through. I am able to run one of the guests like this (assuming vfio stuff has happened elsewhere), but I would prefer to use virsh: kvm -M q35 -m 8192 -cpu host,kvm=off \ -smp 4,sockets=1,cores=4,threads=1 \ -bios

On 08/12/2015 02:34 PM, Alex Holst wrote: > I would really appreciate some pointers on what I am doing wrong here. > > I have a need to run multiple virtual guests which have each their own GPU and > some USB controllers passed-through. I am able to run one of the guests like > this (assuming vfio stuff has happened elsewhere), but I would prefer to use > virsh: > > kvm -M

...ect? On Tue, Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > Hello, > > I noticed that if include\llvm\Support is included alongside Windows.h, > there will be many define conflict leading to compilation errors, such as: > > COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... > }; > > and > > winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > Of course I could try to avoid to include both (but it's rather difficult > and would require lot of refactoring -- we have this clash currently...

On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first include W...

...at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > >> Hello, >> >> I noticed that if include\llvm\Support is included alongside Windows.h, >> there will be many define conflict leading to compilation errors, such as: >> >> COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, >> ... }; >> >> and >> >> winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> Of course I could try to avoid to include both (but it's rather difficult >> and would require lot of refactoring...

...rything right after including Windows.h. On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> > wrote: > > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, > ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first includ...

Quoting Laine Stump (laine@laine.org): > On 08/12/2015 02:34 PM, Alex Holst wrote: > > I would really appreciate some pointers on what I am doing wrong here. > > > > I have a need to run multiple virtual guests which have each their own GPU and > > some USB controllers passed-through. I am able to run one of the guests like > > this (assuming vfio stuff has

...er including Windows.h. > > > On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: >> Right now, we have: >> In COFF.h: >> class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; >> In windows.h: >> #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> * If you first include COFF.h and then windows.h, >> COFF::IMAGE_FILE_MACHINE_UNKNOWN >> will be preprocessed into >> COFF:0. >&gt...

...;> On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik<kledzik at apple.com> wrote: >> >> On Aug 28, 2013, at 7:05 PM, Virgile Bello<virgile.bello at gmail.com> wrote: >> >>> Right now, we have: >>> In COFF.h: >>> class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; >>> In windows.h: >>> #define IMAGE_FILE_MACHINE_UNKNOWN 0 >>> >>> * If you first include COFF.h and then windows.h, >>> COFF::IMAGE_FILE_MACHINE_UNKNOWN >>> will be preprocessed into &gt...

...the packet from passing. For (1) you'd need to run "ebtables -L; iptables -S; nft list ruleset" and look for something suspicious. For (2) can you try changing both the libreelec and the DHCP server vm's ethernet device models from virtio to e1000? (or e1000e if they are q35 machinetypes)? If that works, then change one or the other back and see if it stops working. > should I add another nic with static ip and try to trace the pkts from there? > You mean so you can ssh to the client/libreelec and run tcpdump there agains the interface that's doing dhcp? Is tcpdump...

...mp; Data == E.Data && Private == E.Private); } }; enum class DebugType { None = 0x0, CV = 0x1, /// CodeView PData = 0x2, /// Procedure Data Fixup = 0x4, /// Relocation Table }; struct Configuration { enum ManifestKind { SideBySide, Embed, No }; llvm::COFF::MachineTypes Machine = llvm::COFF::IMAGE_FILE_MACHINE_UNKNOWN; bool Verbose = false; llvm::COFF::WindowsSubsystem Subsystem = llvm::COFF::IMAGE_SUBSYSTEM_UNKNOWN; SymbolBody *Entry = nullptr; bool NoEntry = false; std::string OutputFile; bool DoGC = true; bool DoICF = true; bool Relocatable = tr...

On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Yes of course I understand it was done on purpose. > It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). I too am in the camp that it is a feature to use the standard names. For instance doing a search it google or

On Fri, Dec 04, 2015 at 10:42:30AM +0800, Tashi Lu wrote: > Hi everyone, > > I incidentally configured two IDE controller for my machine-1.2 VM(it > might be virsh attach-disk to blame), and I got the error message > "Only a single IDE controller is unsupported...". I can't understand > this error message, I think it means I HAVE to configure two or more > IDE